Business-to-Business Integration needs a Meta Business Enterprise Ontology

Business-to-business (B2B) integration only succeeds if the messages sent by the cooperating enterprises comply to a business enterprise ontology (BEO). This ensures that the cooperating enterprises have a common understanding of the message exchanged. However, enterprise internal back end application systems follow their own BEO. This requires a transformation between the exchanged messages and the back end application representation. Consequently, throughout the whole B2B integration process, several transformations between BEOs have to take place. This paper will argue for a meta business enterprise ontology (MBEO) that makes sure that the transformations between BEOs preserve the semantics of the messages. Only a MBEO can guarantee that message transformation is semantics preserving. And this is an absolute requirement for successful B2B integration. 1. Business-to-Business (B2B) Integration Standards RosettaNet [13], EDI [7], Bolero [2], and OAGIS [9] are, besides others, four recognized business-to-business (B2B) integration standards that publish document type definitions related to the same particular business domain. Some standards, like RosettaNet, “even” provide a dictionary that contains valid values for specific document type elements. In this case the document type element cannot contain an arbitrary value but must be of one listed in the dictionary. For example, whenever an address is contained in a document the value in the city field must be from a list of cities as defined in the dictionary. The EDI standard, for instance, references hundreds of dictionaries. In addition, the EDI standard cross-references document type elements like an address across different document types. This way it is made explicit which concepts is used by which document type. Each of the standards implements in fact a BEO (business and enterprise ontology). B2B standards are not represented as an explicit set of concepts and relationships between those, but expressed as a welldefined set of document types. For example, all the four standards mentioned earlier contain a definition of a purchase order (PO). Unfortunately, those document type definitions do not match each other in the sense that they provide concept equivalence. (Concept equivalence means here that one or more concepts in one standard can be mapped to one or more concepts in another standard without loosing or adding information.) For instance, OAGIS POs can contain sub-line items whereas RosettaNet POs do not have the concept of a sub-line item. In this situation there is a concept mismatch if a OAGIS PO with sub-line items has to be mapped to a RosettaNet PO without sub-line items. 2. Mapping Business Enterprise Ontologies When is it necessary to map a OAGIS PO to a RosettaNet PO? The context in which this happens is business-to-business (B2B) integration. B2B integration is the formalized exchange of messages between enterprises based on B2B protocols like those mentioned above. A B2B protocol does not only define document types but also the sequence of message exchanges [3] (which is not of relevance for this discussion). From a BEO viewpoint a B2B protocol defines an intermediary format: two organizations that exchange messages usually have their own internal format of storing the documents to be sent or received through messages. In order to send or receive messages, the organizations have to transform the internal representation into the exchange format and vice versa. For example, one organization running the enterprise resource management system SAP [14] extracts a PO from it as an IDOC (interchange document). An IDOC is a SAP specific representation in ASCII format. Before sending the PO to a trading partner over the Internet, it is transformed into the OAGIS defined format since the two organizations agreed to use OAGIS as the interchange BEO. Once the PO in OAGIS format is received by the trading partner, it has to transform the PO into the format that is used within its own environment. In case the trading partner decided to use the RosettaNet defined document types for internal representation, a mapping from OAGIS PO to RosettaNet PO has to take place. If the OAGIS PO sent contains sub-line items, the receiver cannot map the document to RosettaNet because of the reason stated above. The only possibility for the receiver to map the OAGIS document is to modify RosettaNet to incorporate the concept of sub-line items. At this point the local BEO (in the example RosettaNet) is modified and “hopefully” consistently so that all documents that contain line items now can contain also sub-line items. In summary, three BEOs are involved in B2B integration across two enterprises: the one at the sender side, the one at the receiver side and the one that is used as an exchange format, i. e. the messages types and values of elements within messages. The two organizations map two BEOs each: from the local to the interchange BEO and the interchange BEO to the local one. If an organization has several trading partners using different B2B protocols, several mappings from the local to several interchange BEOs have to take place. In this case one organization has to deal with many BEOs at the same time. 3. Challenges of Mapping between BEOs The main problems organizations face is the mapping between BEOs (from local to the exchange BEOs and vice versa). The mapping (sometimes referred to as transformation) between BEOs today is very pragmatic. Mapping tools exist that allow to map from a “left” side to a “right” side. The left side is the source document type and the right side is the target document type. The idea is to map each element of the source document type to one or more elements in the target document type. Several tools exist that allow a graphical specification of mappings between different document types [6] [11]. Some work exists that tries to automate the mapping task to some extent [8]. The mapping has to be done by each company involved in B2B integration individually. In reality the number of exchange formats is limited. So is the number of local BEOs since organizations usually deploy standard applications like SAP [14], Baan [1], Peoplesoft [12], Siebel [15] or Oracle eBusinessSuite [10]. This means that across the industry only a limited number of mappings has to take place: from all the standard applications to all the standard interchange formats and vice versa. Building mappings between the required BEOs is time consuming and requires a lot of knowledge specific to the different standard applications as well as B2B protocols. Only large corporations can afford to maintain all the knowledge to build and maintain their own mappings. Companies like ECBridges [5] and Contivo [4] have seen this situation and provide translation services as third parties so that organizations involved in B2B integration can use those services for document transformation instead of building and maintaining the mappings themselves. The companies mentioned provide translations between the most used formats of the major standard applications. However, by far not all organizations can afford to run major standard applications and make use of the translation services provided by third party companies. Instead, applications are used that are not “mainstream”. Consequently, translation services do not have those in their portfolio of mappings. The reason is that providing mappings for these non-mainstream applications are not profitable. This means that smaller companies have applications that are not supported by third party translation services. However, they are still required to use the major interchange formats since those are dictated by their bigger trading partners. In this case the smaller companies have to maintain their own mappings to the interchange formats and vice versa. Smaller companies face the task to build and maintain mappings between their applications and the exchange BEOs as defined by B2B protocols. 4. Need for a Meta Business Enterprise Ontology From the above discussion two major requirements can be derived: • First, a meta-business and enterprise ontology (MBEO) is necessary that can relate existing BEOs like those provided by B2B integration standards. It must be possible to represent current and future standards as BEOs and provide a mapping between those BEOs that provides concept equivalence. Such a MBEO would contribute to solving the B2B integration problem between enterprises and organizations. • Second, it must be possible to modify a BEO by modifying a subset of its concepts and derive a new “derived” BEO from it (see sub-line item discussion above). Based on the derivation the mappings must be adjusted to that the MBEO can provide the mappings to the derived BEO in addition to the original BEO. This would it make possible for organizations to adjust BEOs to their needs without loosing the benefit of a MBEO. In summary, from an industry viewpoint, developing BEOs (or a “super” BEO) is not of practical relevance. However, developing a MBEO that allows to integrate existing BEOs easily for transformation purposes is very relevant and promises high impact.